Shanghai Silicon Step ROS Serial Series 50 - ROSLink - the bridge between ROS and the Internet of Things (

ROSl ink was first proposed by Dr. Anis Koubaa, who is a professor at the Prince of Saudi Arabia and is also the director of research and development for silicon-step robots. In order to let everyone know about ROSl ink, from the beginning of this issue, we will introduce ROSl ink in three phases.

This issue is the first issue, which mainly introduces the basic concepts of ROSl ink and the background and problems to be solved by ROSl ink.

As a new form of Internet of Things (IoT), the convergence of robots and the Internet is now emerging as an emerging trend. This combination is critical to driving new cloud robot applications that are virtualized, controlled and monitored over the Internet. ROSl ink is a new protocol that combines robots that use robotic operating systems (ROS) with the Internet of Things. The motivation behind the proposed ROSl ink is precisely the lack of ROS function to monitor and control the robot through the Internet. Although ROS allows the robot to be controlled from the workstation using the same ROS master, this solution is not scalable and is limited to local area networks. The solution proposed in the recent work relies on a centralized ROS master or a robot-side web server, which has similar limitations. Inspired by the MAVl ink protocol, the ROSl ink protocol proposed in this paper defines a lightweight asynchronous communication protocol between the robot and the end user through the cloud. ROSl ink uses a proxy cloud server to connect ROS-using robots to users and allow interconnection between them. ROSl ink performance has been tested on the cloud and the display is more efficient and reliable.

1. Introduction

Cloud robots are an emerging trend in the robotics arena to promote robotic applications from two perspectives through the Internet of Things (IoT) and cloud computing technologies: (i) Virtualization: providing seamless robotics through Web and Web services technologies Links, (ii) Remote Brain: Offloading intensive computing from the robot to cloud resources to overcome the computational, storage, and energy constraints of the robot.

Today, the Robotic Operating System (ROS) represents a de facto standard for developing robotic applications. ROS as a middleware, in addition to reusing the open source project library, provides several levels of software abstraction for hardware and robot resources such as sensors and actuators. It is designed to reduce the difficulty of developing large service robots and reduce the complexity of robot software construction. Although ROS is widely used to develop service robot applications, it lacks native support for controlling and monitoring robots over the Internet. It is possible to write ROS nodes (ie programs) in remote workstations on the same local area network (LAN). Both the robot machine and the workstation use the ROS master Uniform Resource Identifier (URI), but controlling the ROS nodes from remote locations is challenging. . To address this limitation, there has been a lot of research work that has raised concerns about client-server architectures.

A milestone in solving this problem is the ROSBridge protocol. It is based on the Websockets server installed on the robot side, which allows the internal state of the robot to be sent according to the ROS theme and service, and receives commands to the Websockets client for processing. This approach enables an effective combination of ROS and the Internet; however, the fact that the Websockets server is running on a robotic machine requires the robot to have a public IP address for Websockets client access, not for all robots, or on the same LAN. NAT can also be used when the robot is behind a network address translation (NAT) domain, but this choice can be cumbersome in actual deployment. In the literature, the author proposes a Web service ROS, which can define a Web service server in the robot, which can be accessed through the network. But this method has the same limitations as ROSBridge, where the server is on the robot side.

This paper fills this gap and proposes a communication protocol ROSl ink that overcomes the above limitations, (i) implements the specification of the robot-side client, and (ii) uses a cloud server, ie, located on a public IP server. A proxy server on the machine. Inspired by the MAVl ink protocol, the robot sends its data serialized messages through a network client to a ground station acting as a server, which receives these messages, processes them, and sends control commands to the robot. In this way, the robot no longer needs a public IP address and can still be accessed after the proxy server.

This article has mainly completed two tasks. First, we propose a new communication protocol, ROSl ink, which defines a three-tier architecture. The ROSl ink Bridge client runs on the robot side; the ROSl ink Proxy acts as a server for the ground station, and a client-side client application that interacts with the robot through the ROSl ink protocol. Secondly, through the experimental research on the ground Turtlebot robot and the AR.Parrot drone , we verified the ROSl ink protocol proposed by us. We show the effectiveness and feasibility of ROSl ink.

2 Background and goals

2.1 Background

The motivation for this paper is to integrate ROS with the Internet of Things. ROS itself does not support monitoring and controlling robots over the Internet. In fact, as shown in Figure 1(a), ROS allows the robot to be controlled from the workstation using the same ROS master, but the solution is not scalable and is limited to use on a local area network. Typically, each robot launches its own ROS master node. If the user configures their ROS network settings to use the same ROS master that the robot is running, the user can control the robot from their workstation. This standard method itself does not allow robots to be controlled via the Internet, as robots usually do not have a public IP address. In some cases it may be considered to use port forwarding behind NAT, but in other cases it may not be possible, for example via 3G / 4G.

One possible solution, as shown in Figure 1(b), is to use a ROS master node for all robots running on a central server with an Internet public IP address. All users will be connected to the same ROS master and access any robot by publishing and subscribing their themes and services. However, this solution also has several limitations. First, some ROS topics, services, and nodes may conflict with each other by having the same name. This requires us to be careful when designing the namespaces of ROS nodes, services, and themes to avoid conflicts. This method becomes complicated when the number of robots is large. The second problem is the lack of scalability. When multiple robots are bound at a given time, the ROS master may be overloaded. In addition to considering the known network problems that some ROS topics are too bandwidth, there is no viable solution to map individual users to their bots because all topics are visible to all users.

Our approach is to design ROSl ink, a lightweight communication protocol inspired by MAVl ink, which allows ROS robots to perform cloud-based interactions with their users, as shown in Figure 1(c). The idea is to add a ROSl ink Bridge to each bot at the top of the ROS so that the bridge can use JSON to serialize messages to send all the states of the robot. The ROSl ink Bridge is a ROS node that accesses all topics and services of interest in the ROS and sends the selected information to the ROS1 ink message serialized using the JSON format. These messages are sent to the ROS1 cloud proxy server, which processes the messages and forwards the messages to a single user and/or multiple users of the bot. In addition, the user sends a command to the bot through the ROS1 cloud cloud agent using the ROS1 ink JSON message, and the command is processed by the ROS1 ink Bridge to perform the corresponding ROS operation. The cloud-based ROSl ink approach has three main advantages: (1) robot-independent ROS master nodes, (2) ensuring seamless communication between users and robots through the cloud, and (3) providing robots, users, and underlying layers. Effective management of services.

(a) Standard method: A typical connection between a ROS robot and a ROS user.

The user connects to the robot's ROS master to control and monitor its status, usually within a local area network.

(b) Central approach: All robots and users are connected to a central ROS master.

This method is not scalable and does not provide effective management of robots and users.

(c) ROSl ink method: A cloud-based solution in which ROS robots and users interact through the cloud.

The ROSl cloud provides management, service-oriented interfaces and real-time data streaming services to users and robots.

Figure 1: ROS operation method

2.2 Overview

The main goal of ROSl ink is to control and monitor robots using ROS via the Internet. In the literature, most of the work is focused on using a two-tier client/server approach where the server is implemented in a robot and the client is implemented in a user application. In fact, most of these studies build remote-controlled robots based on examples of ROSBridge and ROSJS frameworks. ROSBridge represents a milestone in remote control of ROS system remote control robots. However, the disadvantages of this method are: (1) the robot-centric approach, which limits the scalability of the system because the server is concentrated in the robot itself; (2) deployment on the Internet is very difficult because the robot is located in the local area network Internally, you need to have a public IP address or access through a NAT forwarding port.

To overcome these limitations, we propose a ROSl ink that uses a three-tier client/server model where the client is implemented in the bot and the user, while the server is in the public domain and acts as a proxy to connect the bot to its user. ROSl ink overcomes the above two problems. First, there is no longer a server inside the robot, so the robot-centric approach is no longer used. In contrast, the robot implements the client through the ROSL ink Bridge component, which is a ROS node that interacts with ROS on the one hand and ROS data to the outside through a network interface (UDP, TCP, or Websockets). . In addition, the model's ROSl ink server is implemented in a public server called the ROSL ink agent, which acts as an intermediary between the robot and the user. The robot and the user send a message to the proxy server, which sends it to the other end accordingly.

ROSl ink defines a complete abstraction of ROS by defining a communication protocol (inspired by the MAVl ink protocol) that provides all information about the bot through the ROS subject/service without exposing the ROS ecosystem to the user. Users do not need to be familiar with ROS to be able to use ROSl ink to send commands to the robot. ROSl ink defines a set of interfaces for users to interact with the robot, as well as a set of messages used to exchange between them.

ROSl ink messages are built based on ROS topics/service parameters to retrieve or submit data to perform operations. The message is represented by a JSON string. The JSON format is optional for data exchange because it is a platform and language independent data representation format. In addition, it is a more lightweight solution than XML, and is more suitable for resource-constrained and bandwidth-constrained platforms. This will allow client application developers to choose any programming language (C++, Java, Javascript, Python, etc.) to develop a client application that interacts with ROSl ink to command and monitor ROS using ROS.

In short, ROSl ink is different from previous work, especially the difference between ROSBridge and the following:

-ROSl ink implements the client in the bot and user application, and implements the server in the intermediate agent, while ROSBridge implements the Websocket server in the bot and implements the Websocket client in the user application.

-ROSBridge is based on the Websocket protocol, and ROSl ink can be implemented using any transport layer protocol (TCP, UDP and Websockets). In this article, we use UDP and Websockets interfaces to implement ROSl ink.

-ROSl ink does not rely on ROSBridge as in previous studies, but instead defines its own communication protocol between ROS and non-ROS users.